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Title: DOCUMENT CUSTOMIZATION FOR TRANSPARENT EXECUTION ON A 

CLIENT AND A SERVER 

5 

TECHNICAL FIELD 
This invention is related to the creation and processing of customized documents 
in a client/server environment. 

1 0 BACKGROUND OF THE INVENTION 

Certain applications are designed to be "host'' applications, in that, users can 

customize the applications, and build solutions or other apphcations on top of them. 

Examples include spreadsheet and word processing apphcations. In the past, customized 

docxmients that had code embedded could only run or be manipulated on the cHent and 
15 required the full host application to be running. In a server situation, starting an 

application such as the spreadsheet or word processing applications can dramatically 

slow performance and create resource issues. 

SUMMARY OF THE INVENTION 

20 The following presents a simplified siunmary of the invention in order to provide 

a basic understanding of some aspects of the invention. This summary is not an extensive 
overview of the invention. It is not intended to identify key/critical elements of the 
invention or to delineate the scope of the invention. Its sole purpose is to present some 
concepts of the invention in a simplified form as a prelude to the more detailed 

25 description that is presented later. 

The present invention disclosed and claimed herein, in one aspect thereof, 
comprises a system that faciUtates the creation of a customized document with embedded 
or linked to code that can be run on the client inside of the host application (e.g., a word 
processing or spreadsheet application) or run on the server without invoking the host 

30 application. Thus, not only is the code agnostic as to where it is executing, it can actually 
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execute with or without invoking the host application, as appropriate, leading to, for 
example, great performance gains. 

In yet another aspect thereof, the programming model automatically ''scales" to 
provide more features while running on the client and less features when running on the 
5 server. 

In still another aspect of the invention, a transparent data island is automatically 
generated for the customized document that is embedded in the document and can be 
edited while requiring only a subset of all components of the host application to be 
running or no components of the host need run on the server at all. 

10 In another aspect thereof, a mechanism is provided that facilitates data binding 

whereby changes that are made to the transparent data island while the host is not running 
can be moved back into the host document content when the document is reopened by the 
full host application. 

To the accomplishment of the foregoing and related ends, certain illustrative 

15 aspects of the invention are described herein in connection with the following description 
and the annexed drawings. These aspects are indicative, however, of but a few of the 
various ways in which the principles of the invention may be employed and the present 
invention is intended to include all such aspects and their equivalents. Other advantages 
and novel features of the invention may become apparent from the following detailed 

20 description of the invention when considered in conjunction with the drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 illustrates a block diagram of a system of the present invention. 
FIG. 2 illustrates a flow chart of a process of code embedding of the present 
25 invention. 

FIG. 3 illustrates a block diagram of a relationship of the host, view and data 
models, in accordance with the present invention. 

FIG. 4 illustrates a flow chart of creating a data island in accordance with the 
present invention. 

30 FIG. 5 illustrates a flow chart of data binding in accordance with the present 

invention. 
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FIG. 6 illustrates a block diagram for scaling in accordance with the present 
invention. 

FIG. 7 illustrates a flow chart of a scalable feature in accordance with the present 
invention. 

5 FIG. 8 illustrates a block diagram of a computer operable to execute the disclosed 

architecture. 

FIG. 9 illustrates a schematic block diagram of an exemplary computing 
environment in accordance with the present invention. 

10 DETAILED DESCRIPTION OF THE INVENTION 

The present invention is now described with reference to the drawings, wherein 
like reference numerals are used to refer to like elements throughout. In the following 
description, for purposes of explanation, numerous specific details are set forth in order 
to provide a thorough understanding of the present invention. It may be evident, 

1 5 however, that the present invention may be practiced without these specific details. In 
other instances, well-known structures and devices are shown in block diagram form in 
order to facilitate describing the present invention. 

As used in this application, the terms "component" and "system" are intended to 
refer to a computer-related entity, either hardware, a combination of hardware and 

20 software, software, or software in execution. For example, a component may be, but is 
not limited to being, a process running on a processor, a processor, an object, an 
executable, a thread of execution, a program, and/or a computer. By way of illustration, 
both an application running on a server and the server can be a component. One or more 
components may reside within a process and/or thread of execution and a component 

25 may be localized on one computer and/or distributed between two or more computers. 

Referring now to FIG. 1, there is illustrated a block diagram of a system 100 of 
the present invention. The system includes a host application 102 that is used to create a 
customized document 104. The host application 102 can be a word processing 
application, or a spreadsheet application, for example. A programming component 106 

30 interfaces to the host application 1 02 to facilitate at least embedding the code 1 08 in the 
document 104. The embedded code 108 facilitates running of the document 104 in the 
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client application and/or the server application by requiring only a subset of all 
components of the host application 102. Alternatively, the code can be linked to by the 
document and can be stored outside the document. 

In the past, the only option a programmer (or developer) had when developing a 
5 customized document was to write code against a generic API (Application Program 
Interface) provided by the host application 102. The present invention generates view 
and data programming models that conform to schemas provided by the developer. In 
support thereof, the programming component 106 includes both a view component 1 10 
and a data component 1 12. The programming component 106 facilitates separating 

10 document view elements (or content) from document data (or data elements). Thus, the 
data component facilitates the automatic creation of a data island 1 14 in the customized 
document 104. The data in the data island 1 14 can be edited without requiring the host 
application 102 to be fully operational. That is, only a subset of the application 
components needs to be activated to edit the data. 

1 5 The customized document 1 04 can then be run on the client inside the host 

application 102 or on the server without invoking the host application 102. Thus, not 
only is the embedded code agnostic as to where it is executing, it can actually execute 
with or without invoking the host application, as appropriate, leading to, for example, 
great performance gains. The programming model makes it transparent to the embedded 

20 code whether it is running on the client or the server. 

Referring now to FIG. 2, there is illustrated a flow chart of a process of code 
embedding of the present invention. Though, for purposes of simplicity of explanation, 
the one or more methodologies shown herein, e.g., in the form of a flow chart, are shown 
and described as a series of acts, it is to be understood and appreciated that the present 

25 invention is not limited by the order of acts, as some acts may, in accordance with the 
present invention, occur in a different order and/or concurrently with other acts from that 
shown and described herein. For example, those skilled in the art will understand and 
appreciate that a methodology could alternatively be represented as a series of 
interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts 

30 may be required to implement a methodology in accordance with the present invention. 
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At 200, the user/developer creates a document using the host application. At 202, 
the programming facilitates embedding code in the document such that the document can 
be run on the client and the server without invoking the host application. At 204, the 
programming model adds scaling capability such that the available features scale 
5 according to whether the document is run on the client or the server. The process then 
reaches a Stop block. 

Referring now to FIG. 3, there is illustrated a block diagram of a relationship of 
the host, view and data models, in accordance with the present invention. The host object 
model 300 is available for host compatibility and control. The programming component 

1 0 of the present invention separates the document contents into data content and view 

content using the corresponding data and view components (or models). The view model 
302 (similar to the view component 1 10) interfaces to the host model 300 via a view 
control hookup mechanism. The data model 304 (similar to the data component 1 12) 
interfaces to host object model 300 through the view model 302 via data binding to the 

15 view model 302. The view model 302 and data model 304 are schema models specific to 
the application being created. The customization code can choose to not invoke the 
*'view" manipulating code on the server. The "data' manipulating portion of the 
customization code does not know or care whether it is running on the client or the 
server. The following sample code illustrates the relationships for each. 

20 

Host Model 

Dim w as Worksheet 
w = ThisWorkBook. Sheets (2) 
25 w.Range("$F$ll") .Value2 = 12345 

View Model 

CustomerIDCell.Value2 = 12345 
30 CustomerlDCell. Font. Bold = True 

Data Model 

Customer. ID = 12345 
35 Customers [0] . FirstName = "John" 
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Following is sample code that illustrates the relationship between the view model 
302 and the host object model 300. 

5 

ExpenseReportView. Customer .ID. Font .Name 

The code "ExpenseReportview.Customer . id" is the portion generated from 
user-defined schema. The period (.) after "id" is the connection between the generated 
10 view model to the correct host object model object made by using the schema to the host 
view element mapping information. The code "Font . Name" is a property provided by the 
spreadsheet application specific object model. Font is a property of the Range object that 
represents a cell. 

Referring now to FIG. 4, there is illustrated a flow chart of the creating a data 
1 5 island in accordance with the present invention. At 400, the document is created using 
the host application. At 402, the contents of the document are separated into view 
content and data content. At 404, a data island of the data content is automatically 
created in the document. The data in the data island is accessible by both the host 
application running on the client or by the server. The data island can be edited while 
20 requiring only a subset of all components of the host application to be running. The 
process then reaches a Stop block. 

Referring now to FIG. 5, there is illustrated a flow chart of data binding in 
accordance with the present invention. At 500, the document is created using the host 
application. At 502, the contents of the document are separated into view content and 
25 data content. At 504, a data island of the data content is automatically created in the 
document. At 506, the document data changes are bound to the host document content 
when the document is reopened by the full host application. The process then reaches a 
Stop block. 

Some interesting scenarios enabled by code running on the client or server include 
30 the scenario where some code is embedded in a spreadsheet document. When the 

spreadsheet document is posted to a server site for sharing or access, the embedded code 
can execute and perform interesting tasks without requiring start of the spreadsheet 
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application (which would require the spreadsheet application to be running on the server). 
The spreadsheet could be exposed as a web service. A runtime program could execute 
just the embedded code associated with that spreadsheet document, and run it on the 
server to field web service requests. Data contained in a spreadsheet data island can be 
5 exposed out to web pages and other views, all without starting the host application. The 
present invention allows the same code to run on the client or server against the 
embedded data island that is automatically created in the document. 

Feature Scaling Between Client and Server 

10 The generated programming model for the document scales between use on a 

client and a server. That is, the model runs in a lower functionality on the server than on 
the client. This reduction in functionality is transparent to the code being written. This 
transparency is enabled by combining several techniques. 

Referring now to FIG. 6 there is illustrated a block diagram for scaling in 

1 5 accordance with the present invention. The document 1 04 includes both the data island 
1 14 and the embedded code 108. Separate from the embedded code 108 or as part of the 
embedded code 108, there is provided a coupling component 600 that facilitates scaling 
the features for running the document on a client 602 and/or a server 604. Thus, if the 
coupling component 600 determines that the document 104 is being launched from the 

20 client 602, scaling-up is provided where coupling will occur at least between the data 
model and the view model to provide increase functionality for accessing and processing 
both view and data elements of the document 104. On the other hand, if the coupling 
component 600 determines that the document 104 is being executed on the server 604, a 
scaling-down effect is imposed to reduce functionality which is provided by, in one 

25 embodiment, not coupling the data model to the view model. In another embodiment, if 
the server 602 includes a lightweight API (which does not involve starting the entire host 
application) that provides limited capabilities of the host application such as limited 
access to a view model, the data model will be coupled to the view model to allow view 
access. 

30 Referring now to FIG. 7, there is illustrated a flow chart of a scalable feature in 

accordance with the present invention. At 700, a document is created using the host 
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application. At 702, a loosely coupled programming model is generated for the 
document by separating the document into a view model and a data model. 

In the past, the only option a programmer had when developing a customized 
document was to write code against the generic general purpose API provided by the host 
5 application. The view and data programming models of the present invention conform to 
schemas provided by the developer. For example, the developer may have a spreadsheet 
that contains an ID associated with a customer. Assume that this ID is located in Column 
A, Row 2, and the developer wants to set its value to "12345". Traditionally, the generic 
way for the spreadsheet API to talk to that ID is writing code such as the following. 

10 

Workbook. Sheets (1) .Range{"$A$2") .Value = 12345 

The present invention provides a schema for Customer and a mapping from 
Customer . ID to its actual location in the spreadsheet. Thus, two additional generated 
1 5 programming models are provided that give the developer a schema-oriented way to talk 
to the ID in the spreadsheet, and that are easier to understand and use domain names 
provided by the developers. 

First, the view model gives a programmable name" to generic API objects and 
exposes these objects out as "view controls" that can be easily discovered and against 
20 which they can be easily programmed. The view model way of changing the customer 
ID looks as following. 

Customer IDCell. Value = 12345 

25 With the view model, the developer can also write code to change other attributes 

of the cell that are not data specific, but are view specific. For example: 

CustomerlDCell .Value = 12345 
CustomerlDCell . BackColor = Green 
30 CustomerlDCell .Width = 100 

Second, the data model only allows the developer to change the data of interest in 
the document. The data model way of representing the customer ID is as follows. 

8 
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Customer. ID = 12345 

The data model acts indirectly against the view via data binding. All three 
5 models — the host API, the view model, and the data model — are loosely coupled. This 
results in three separate loosely coupled programming models as shown in FIG. 3. At 
704, the data and code are then embedded in the document. 

A second reason for code transparency is that the three programming models 
(Host, View, and Data) are loosely coupled and can be started up independently of one 

10 another. This is important to code transparency by enabling execution of the document 
regardless of where it will be processed, on the client and/or on the server. At 706, the 
system determines if the document will be run on the client. If not, flow is to 708 to 
invoke the server model of the embedded code. On the server, in most cases, only the 
data programming model is started. No coupling is initiated between the data model and 

1 5 the view model using data binding because doing so would require the host application to 
execute. However, at 710, if the system determines that a lightweight API for the view 
model exists on the host that can be connected to on the server that possibly acts against 
the document contents without starting up the full host, the present invention provides a 
mechanism to start the view model on the server against lighter weight, but interface 

20 equivalent, objects, as indicated at 712. 

The independent startup of programming models is made possible by indirection 
built in-between each programming model. The data model is hooked to the view model 
by data binding. The view model is hooked to the host API via a view control hookup 
mechanism. These points of coupling are intentionally loose and flexible enabling 

25 variation in how much of the programming model is available on both the client and the 
server. Independent startup is also made possible by having two standard entry points for 
our document customizations — a "CreateForClient" and "CreateForServer". These entry 
points configure the programming model differently depending on if the programming 
model is being started on the server or the client. 

30 A third feature that supports code transparency is that the code is data centric. 

Code written against the data component runs equally well on the client or the server. 
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The more code the developer writes against the data model, the better the capability the 
document will have to run on the client and the server. 

A fourth feature that supports code transparency for scalability is that 
programming is event centric. Code runs in response to a particular triggering event. On 
5 the client, some triggering events include a double-click event or a right-click event. 
Traditionally, code written against these types of events typically use features only 
available when the entire host application and all three programming models are running. 
On the server, the double-click event will not trigger because it is an event that only 
triggers on the client. Therefore, code will not be run that requires the view or host API 

10 programming models. On the server, a separate set of triggering events occurs that can 
be handled. Code written to handle these events must be written against the data 
programming model, as that potentially will be the only programming model that starts 
on the server. In support thereof, at 714, the system processes server-triggered events. 
A fifth feature that supports code transparency for scalability is that of runtime 

1 5 exceptions. At runtime, certain parts of the programming model (the view and the host 
API's) are not guaranteed to be hooked up. If code written against these parts of the 
programming model is run on the server, a runtime exception will occur that helps the 
developer discover the parts of the program that need to be rewritten using the data 
programming model or changed so it will not be run on the server. 

20 A sixth feature that supports code transparency for scalability is that of limited 

user interface (UI) permissions on the server. In addition to the attempt to access the 
view-programming model on the server, the developer might attempt to display other UI 
such as dialog boxes. This is not desirable on the server. For this reason, permission to 
the customized document is restricted when it is running on the server, to not allow UI to 

25 be displayed. Doing so will result in a runtime exception. At 716, runtime exceptions 
are processed, including those for UI permissions. 

A seventh feature that supports code transparency for scalability is that of 
client/server attributing. Sometimes, it may be impossible to have the same data code run 
on the client and server. For example, the resources available on the client may be 

30 different from the resources available on the server. The client may not have a local 

database available, while the server does. For these cases, data code can be marked with 
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an attribute to indicate where it is allowed to run {i.e., on the client, on the server, or 
both). At 718, the system processes the attributed code. 

If the lightweight API does not exist, flow is from 710 to 714 to process server 
triggering events. 

5 If the system determines that the document will be run on the client, flow is from 

706 to 720 to invoke the client model by starting the data model. At 722, the view model 
is started. At 724, the data model is then bound to the view model. At 726, the system 
processes client-triggering events, as indicated hereinabove. Flow is then to 716 and 718 
to process runtime exceptions and attributed code. The process then reaches a Stop 

10 block. 



Data Island Transparency 

There are several reasons to actually keep data separate from the document 
content. Keeping the data in the document content requires that each data element be 

1 5 mapped to a document view element, when in reality, there is often data that is desired to 
be maintained and manipulated but not displayed or stored in the document content. For 
example, an employee ID can be part of the data model but not actually displayed in the 
document contents or in the view model. 

Another reason for separating data from content is that many modem applications 

20 have document file formats that are not transparent or are very difficult to retrieve data 
from if the host application is not running. Traditionally, the host application has to be 
run to read or modify data that is contained in the document content. This is inefficient 
for scenarios such as servers where a web page is accessed to quickly retrieve and display 
important data in a document, yet it is needed or required to start the entire host 

25 application to get the data from the document. 

Developers normally want to deal directly with the data, and not have to start the 
host application to read data from document content. Given a schema for the data in the 
document, the present invention automatically separates the data from the view by 
generating and saving a data island in the document that conforms to the data schema 

30 created by the developer. This data schema is the same schema used to create the data 
model. This data island can be accessed and modified on the server without having to 

11 
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start the host application. Moreover, each time the document runs inside the host 
application, the contents of this data island are synchronized with the document contents. 
Additionally, the generated data model is connected to the data island so that the data 
model works directly against data. Changes to the data model are then moved into the 
5 document contents via the data binding mechanism to view controls described herein. 

The developer may mark any data being used as "cached" by using a custom 
attribute. The document data can be cached by taking advantage that the document can 
be stored in an OLE (Object Linking and Embedding) structured storage (or document). 
An OLE structured storage is a standard, operating-system-provided file format that 

10 allows a file (or document) to act as a collection of directories (called "storages") and 
files (called "streams"). A storage is created in the document and a stream is created to 
hold the persisted state of the cached data. When the document customization is created 
on either the client or the server, the cached data is reconstituted out of the stream. The 
customization code can then manipulate the data, and store any changes back into the 

1 5 stream. It is to be appreciated by one skilled in the art that the present invention is not 
limited to the use of OLE structured storage documents. Other file formats can also 
support the insertion of a data island. For example, if the file format is XML it is easy to 
insert a data island in it. Even if the file format is a binary file format, if the host can 
provide a reader and writer to insert the data island into the binary file, that reader and 

20 writer can be used without starting up the fiill host application to edit the data island. 

Data Binding 

As indicated previously, the data and view programming models are loosely 
coupled using data binding whereby data elements are bound to view elements, hi a 

25 scenario with no view (for example, when running the code in a server process) the view 
programming model is not started up and the data binding is not used. Only the data- 
programming model is started. The data island may be changed and the document 
updated. However, the contents of the document — the actual view — will not have the 
new state of the data, because the full host application has to be started to edit the view 

30 which is typically in a non-transparent part of the document. The changes made to the 
data island are moved into the view of the document the next time the document is 
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opened by the fiill host application. When the document is opened by the host 
application, all three programming models are started, and during startup, the data 
binding that connects the data model to the view moves the data out of the data island 
into the view. In this way, the view is updated to display the latest data. 
5 Referring now to FIG. 8, there is illustrated a block diagram of a computer 

operable to execute the disclosed architecture. In order to provide additional context for 
various aspects of the present invention, FIG. 8 and the following discussion are intended 
to provide a brief, general description of a suitable computing environment 800 in which 
the various aspects of the present invention may be implemented. While the invention 

10 has been described above in the general context of computer-executable instructions that 
may run on one or more computers, those skilled in the art will recognize that the 
invention also may be implemented in combination with other program modules and/or 
as a combination of hardware and software. 

Generally, program modules include routines, programs, components, data 

1 5 structures, etc., that perform particular tasks or implement particular abstract data types. 
Moreover, those skilled in the art will appreciate that the inventive methods may be 
practiced with other computer system configurations, including single-processor or 
multiprocessor computer systems, minicomputers, mainframe computers, as well as 
personal computers, hand-held computing devices, microprocessor-based or 

20 programmable consumer electronics, and the like, each of which may be operatively 
coupled to one or more associated devices. 

The illustrated aspects of the invention may also be practiced in distributed 
computing environments where certain tasks are performed by remote processing devices 
that are linked through a communications network. In a distributed computing 

25 environment, program modules may be located in both local and remote memory storage 
devices. 

A computer typically includes a variety of computer-readable media. 
Computer-readable media can be any available media that can be accessed by the 
computer and includes both volatile and nonvolatile media, removable and non- 
30 removable media. By way of example, and not limitation, computer readable media can 
comprise computer storage media and communication media. Computer storage media 

13 
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includes both volatile and nonvolatile, removable and non-removable media implemented 
in any method or technology for storage of information such as computer readable 
instructions, data structures, program modules or other data. Computer storage media 
includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory 
5 technology, CD-ROM, digital video disk (DVD) or other optical disk storage, magnetic 
cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any 
other medium which can be used to store the desired information and which can be 
accessed by the computer. 

Communication media typically embodies computer-readable instructions, data 

10 structures, program modules or other data in a modulated data signal such as a carrier 
wave or other transport mechanism, and includes any information delivery media. The 
term "modulated data signal" means a signal that has one or more of its characteristics set 
or changed in such a manner as to encode information in the signal. By way of example, 
and not limitation, communication media includes wired media such as a wired network 

1 5 or direct-wired connection, and wireless media such as acoustic, RF, infrared and other 
wireless media. Combinations of the any of the above should also be included within the 
scope of computer-readable media. 

With reference again to FIG. 8, there is illustrated an exemplary environment 800 
for implementing various aspects of the invention that includes a computer 802, the 

20 computer 802 including a processing unit 804, a system memory 806 and a system bus 
808. The system bus 808 couples system components including, but not limited to, the 
system memory 806 to the processing unit 804. The processing unit 804 may be any of 
various commercially available processors. Dual microprocessors and other 
multi-processor architectures may also be employed as the processing unit 804. 

25 The system bus 808 can be any of several types of bus structure that may further 

interconnect to a memory bus (with or without a memory controller), a peripheral bus, 
and a local bus using any of a variety of commercially available bus architectures. The 
system memory 806 includes read only memory (ROM) 810 and random access memory 
(RAM) 812. A basic input/output system (BIOS) is stored in a non-volatile memory 810 

30 such as ROM, EPROM, EEPROM, which BIOS contains the basic routines that help to 
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transfer information between elements within the computer 802, such as during start-up. 

The RAM 812 can also include a high-speed RAM such as static RAM for caching data. 
The computer 802 further includes an internal hard disk drive (HDD) 814 (e.g., 

HIDE, SATA), which internal hard disk drive 814 may also be configured for external 
5 use in a suitable chassis (not shown), a magnetic floppy disk drive (FDD) 816, (e.g.. to 

read from or write to a removable diskette 818) and an optical disk drive 820, {e.g., 

reading a CD-ROM disk 822 or, to read from or write to other high capacity optical 

media such as the DVD). The hard disk drive 814, magnetic disk drive 816 and optical 

disk drive 820 can be connected to the system bus 808 by a hard disk drive interface 824, 
10 a magnetic disk drive interface 826 and an optical drive interface 828, respectively. The 

interface 824 for external drive implementations includes at least one or both of 

Universal Serial Bus (USB) and IEEE 894 interface technologies. 

The drives and their associated computer-readable media provide nonvolatile 

storage of data, data structures, computer-executable instructions, and so forth. For the 
1 5 computer 802, the drives and media accommodate the storage of any data in a suitable 

digital format. Although the description of computer-readable media above refers to a 

HDD, a removable magnetic diskette, and a removable optical media such as a CD or 

DVD, it should be appreciated by those skilled in the art that other types of media which 

are readable by a computer, such as zip drives, magnetic cassettes, flash memory cards, 
20 cartridges, and the like, may also be used in the exemplary operating environment, and 

further, that any such media may contain computer-executable instructions for 

performing the methods of the present invention. 

A number of program modules can be stored in the drives and RAM 812, 

including an operating system 830, one or more application programs 832, other program 
25 modules 834 and program data 836. All or portions of the operating system, applications, 

modules, and/or data can also be cached in the RAM 812. 

It is appreciated that the present invention can be implemented with various 

commercially available operating systems or combinations of operating systems. 

A user can enter commands and information into the computer 802 through one or 
30 more wired/wireless input devices, e.g., a keyboard 838 and a pointing device, such as a 

mouse 840. Other input devices (not shown) may include a microphone, an IR remote 

15 
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control, a joystick, a game pad, a stylus pen, touch screen, or the like. These and other 
input devices are often connected to the processing unit 804 through an input device 
interface 842 that is coupled to the system bus 808, but may be connected by other 
interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an 
5 IR interface, etc. 

A monitor 844 or other type of display device is also connected to the system bus 
808 via an interface, such as a video adapter 846. In addition to the monitor 844, a 
computer typically includes other peripheral output devices (not shown), such as 
speakers, printers etc. 

1 0 The computer 802 may operate in a networked environment using logical 

connections via wired and/or wireless communications to one or more remote computers, 
such as a remote computer(s) 848. The remote computer(s) 848 may be a workstation, a 
server computer, a router, a personal computer, portable computer, microprocessor-based 
entertainment appliance, a peer device or other common network node, and typically 

15 includes many or all of the elements described relative to the computer 802, although, for 
purposes of brevity, only a memory storage device 850 is illustrated. The logical 
connections depicted include wired/wireless connectivity to a local area network (LAN) 
852 and/or larger networks, e.g., a wide area network (WAN) 854. Such LAN and WAN 
networking environments are commonplace in offices, and companies, and facilitate 

20 enterprise-wide computer networks, such as intranets, all of which may connect to a 
global communication network, e.g., the Internet. 

When used in a LAN networking environment, the computer 802 is connected to 
the local network 852 through a wired and/or wireless communication network interface 
or adapter 856. The adaptor 856 may facilitate wired or wireless communication to the 

25 LAN 852, which may also include a wireless access point disposed thereon for 
communicating with the wireless adaptor 856. When used in a WAN networking 
environment, the computer 802 can include a modem 858, or is connected to a 
communications server on the LAN, or has other means for establishing communications 
over the WAN 854, such as by way of the Internet. The modem 858, which may be 

30 internal or external and a wired or wireless device, is connected to the system bus 808 via 
the serial port interface 842. In a networked environment, program modules depicted 
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relative to the computer 802, or portions thereof, may be stored in the remote 
memory/storage device 850. It will be appreciated that the network connections shown 
are exemplary and other means of establishing a communications link between the 
computers may be used. 
5 The computer 802 is operable to communicate with any wireless devices or 

entities operably disposed in wireless communication, e.g.^ a printer, scanner, desktop 
and/or portable computer, portable data assistant, communications satellite, any piece of 
equipment or location associated with a wirelessly detectable tag {e.g., a kiosk, news 
stand, restroom), and telephone. This includes at least Wi-Fi and Bluetooth^^ wireless 

1 0 technologies. Thus, the communication may be a predefined structure as with 

conventional network or simply an ad hoc communication between at least two devices. 

Wi-Fi, or Wireless Fidelity, allows connection to the Internet from a couch at 
home, a bed in a hotel room or a conference room at work, without wires. Wi-Fi is a 
wireless technology like a cell phone that enables such devices, e.g., computers, to send 

15 and receive data indoors and out; anywhere within the range of a base station. Wi-Fi 
networks use radio technologies called IEEE 802, 1 1 (a, b, g, etc.) to provide secure, 
reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers 
to each other, to the Internet, and to wired networks (which use IEEE 802.3 or Ethernet). 
Wi-Fi networks operate in the unlicensed 2.4 and 5 GHz radio bands, with an 1 1 Mbps 

20 (802. 1 1 b) or 54 Mbps (802. 1 1 a) data rate or with products that contain both bands (dual 
band), so the networks can provide real-world performance similar to the basic lOBaseT 
wired Ethernet networks used in many offices. 

Referring now to FIG. 9, there is illustrated a schematic block diagram of an 
exemplary computing environment 900 in accordance with the present invention. The 

25 system 900 includes one or more client(s) 902. The client(s) 902 can be hardware and/or 
software {e.g., threads, processes, computing devices). The client(s) 902 can house 
cookie(s) and/or associated contextual information by employing the present invention, 
for example. The system 900 also includes one or more server(s) 904. The server(s) 904 
can also be hardware and/or software {e.g., threads, processes, computing devices). The 

30 servers 904 can house threads to perform transformations by employing the present 

invention, for example. One possible communication between a client 902 and a server 



17 



MS306136.01 

904 may be in the form of a data packet adapted to be transmitted between two or more 
computer processes. The data packet may include a cookie and/or associated contextual 
information, for example. The system 900 includes a communication framework 906 
{e.g., a global communication network such as the Internet) that can be employed to 
5 facilitate communications between the client(s) 902 and the server(s) 904. 

Communications may be facilitated via a wired (including optical fiber) and/or 
wireless technology. The client(s) 902 are operably connected to one or more client data 
store(s) 908 that can be employed to store information local to the client(s) 902 {e.g., 
cookie(s) and/or associated contextual information). Similarly, the server(s) 904 are 

1 0 operably connected to one or more server data store(s) 910 that can be employed to store 
information local to the servers 904. 

What has been described above includes examples of the present invention. It is, 
of course, not possible to describe every conceivable combination of components or 
methodologies for purposes of describing the present invention, but one of ordinary skill 

1 5 in the art may recognize that many fiarther combinations and permutations of the present 
invention are possible. Accordingly, the present invention is intended to embrace all 
such alterations, modifications and variations that fall within the spirit and scope of the 
appended claims. Furthermore, to the extent that the term "includes" is used in either the 
detailed description or the claims, such term is intended to be inclusive in a manner 

20 similar to the term "comprising" as "comprising" is interpreted when employed as a 
transitional word in a claim. 
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